想像明天早上的 Daily：大家帶著查核結果來，一份寫「還要再查」，一份寫「可以交人確認」，還有好幾份被退回。接著有人問：「所以今天先做哪件？缺的證據誰去要？」

這是第三幕「方法離開作者」的最後一篇。前幾天，我已經留下 Skill、系統 Wiki、自動檢查與工具組。前兩天測的是「這套查法換個環境能不能跑，以及改過後判得對不對」。每跑一次，就留下一份結果：查了哪種情境、找到什麼證據、自動檢查有沒有通過。Day 20 留下 4 份，Day 21 留下 27 份，合計 31 份。

這些是同幾種教學情境反覆執行的紀錄，不是 31 件通知事故。今天換個問題：假如團隊拿到這些結果，能不能知道哪些要補查、哪些等待決定，以及下一步由誰接？

先看結果裡有什麼 → 請 Claude 整理下一步 → 把分工約定寫清楚 → 用 hook 檢查、用 Mod 看見卡點。

這次演練先定義三種角色，看看查核結果該由誰接：

誰該接什麼，我心裡很清楚：還缺證據的，交給查核者去要；證據齊了、等著做決定的，才交給負責人。 既然這麼清楚，排工作應該可以交給 Claude。這次先驗分派結果，還沒有真人團隊採用的紀錄。

前兩天留下的結果，今天要怎麼接著做？

這 31 份包含重複試跑與不同測試情境，不能直接當成 31 件待辦。先看自動檢查給的狀態：

退回佔 58%，看起來像一半以上都失敗。但這些是要重查，還是只差寫法？還要再查的又在等誰？狀態數字回答不了。

先請 Claude 整理：誰接、接下來做什麼？

我把 31 筆原始結果放進一個乾淨目錄，請 Claude 排出今天的工作清單。提示裡沒有寫誰該接哪件事，因為我以為這是常識。注意下面這段只限定「誰接」能填哪三種角色，沒有任何分派規則：

請排出團隊今天要處理的工作清單：重複的自行判斷要不要合併；unknown 怎麼處理由你判斷。
每件寫：標題、下一步、誰接（只能填：服務 Owner／查核者／Skill 維護者）、在等什麼、
合併了哪些結果編號、今天要不要處理。寫成 out/worklist.json。

（unknown 是還不能確定。）同一份輸入跑 3 次（Sonnet 5.5，只給讀檔和寫 out/ 的權限）。

它做對的： 3 次都沒被 58% 帶偏，知道那 18 筆答案是對的、只差寫法，今天不用處理。

它排錯的是誰接。 兩件在等對方回條的工作，照我心裡的規則該交給查核者去要；Claude 3 次都交給負責人，而且都排今天。看 owner 和 today 這兩行：

{
  "title": "找不到接收端收據（receipts.json 缺失）：接收端狀態 unknown",
  "owner": "服務 Owner",
  "waiting_for": "接收端 fake sink 的收據檔／請求紀錄（含 payload）",
  "today": true
}

照我心裡的規則，負責人今天只該決定 1 件；照 Claude 的清單是 3、3、2 件，他得先把不該他做的事轉手出去。

我以為是常識，結果只有我知道

我第一個反應是：「這不是很明顯嗎？」接著回頭找，這條規則寫在哪裡。

哪裡都沒寫。 Skill 沒寫，Wiki 沒寫，前幾天的交接文件也沒寫。這條規則一直只在我腦中，我每次看完結果，順手就分好了。Claude 不是排錯，是猜不到一條從來沒寫下來的規則。

要確認是不是這樣，我把規則寫成一行，加進提示，其他一字不改，再跑 3 次：

團隊分派政策：缺資料（例如收據、紀錄不齊）交查核者去要；只有條件齊全、等待決定的才交服務 Owner。

一行規則，3 次都照做，負責人每次都只剩 1 件。

所以 Skill 留下了共同查法，卻沒寫：缺證據由誰補查，證據齊了由誰拍板。 如果把這樣的方法交給團隊，就可能有人以為別人會去補資料，也可能把還沒查完的工作全推給負責人。查得更快，不代表問題就能更快被接著處理。

分工寫清楚了，怎麼避免下次又漏掉？

但「這 3 次照做」不等於「每次都會照做」。Day 19 的檢查程式，是我在外面一次一次跑；每天排工作時，沒有人會在外面幫每份清單跑檢查。

hook 是 Claude Code 在固定時機（例如 Claude 要結束回答時）自動執行的小程式，不必靠 Claude 記得，可以放行，也可以退回。

官方文件對這種情況寫得很直接：「Claude skipped a rule that must hold every time: move the rule into a hook.」這讓我把查法與自動檢查分開。加上下一節會用到的 Mod，本篇採用的分工是：

所以第三組，我把提示改回第一次那樣，一樣不寫規則，改掛一個 Stop hook：Claude 要結束時，hook 自動檢查工作清單。這版先用等待欄位的關鍵字判斷（MISSING 比對「收據、紀錄、資料」等字詞）：它能重現本次退件，但沒有實際查證證據是否齊全，已知缺口列在文末。

for it in items:
    owner, wait = it.get('owner', ''), it.get('waiting_for', '')
    if '服務 Owner' in owner and MISSING.search(wait):   # 還缺證據卻交給服務 Owner
        bad.append(it.get('title', ''))
if bad and not inp.get('stop_hook_active'):             # 同一輪只擋一次，避免無限循環
    print(json.dumps({'decision': 'block', 'reason': '還缺證據的工作要交給查核者……'}))

本例為了避免無限重排，同一輪只阻擋一次。這能要求 Claude 修正一次，並不保證修正後仍違規就一定無法結束。

3 次都先排錯，3 次都被擋下來改掉。 這 3 次裡提示寫一行和 hook 都守住了，數據還分不出哪個更可靠；差別在表上最後一列：靠記得，還是靠檢查，代價是每次多約 14 秒、US$0.03。

但第 3 次的「0 件」不是好事，要打開看板才看得出來。

檢查跑完了，工作真的交對人了嗎？

Mod 是裝進 Claude Code 的小外掛，可以在旁邊開一個面板，把檔案裡的狀態畫給人看。

這次 hook 的工作是檢查分派並留下退件紀錄。Daily 上大家想知道的是「每件事做到哪一步、卡在哪裡、誰該接」，所以我再寫了一個 Mod，在 Claude Code 右邊開一個看板。每件工作列出四步：① 發送端 ② 接收端 ③ 自動檢查 ④ 交給誰。它不重新判定分派是否違規，狀態直接讀查核結果、工作清單和 hook 留下的紀錄；看板不再複製一份退件規則。

看第三件「正常案例」：① 發送端、② 接收端都已確認，③ 有 4 筆可以交人確認，④ 卻交給了查核者。

看板一打開，問題就很明顯：證據已經齊了的那件，被交給了負責去要證據的人。 這是第 3 次的結果，也是表上那個「0 件」的原因。hook 沒有擋，因為它只守寫下的那一條規則「缺證據的不能交負責人」；反方向的錯，「證據齊了卻沒交給負責人」，不在它的檢查範圍裡。

我自己也踩了一個坑：第一版看板我在裡面又寫了一次「等證據」的判斷，結果把對的工作標成紅色。同一條規則各寫一份，就可能互相對不起來。 所以這條退件規則留在 hook，看板只呈現結果，不再自行重判。

今天先處理哪件？

下面這張不是 Claude 的輸出，是 build_view.py 照事先寫好的案例規則產生的對照清單（節錄五項）：拿來核對 Claude 排得對不對，但只涵蓋這三種已定義的案例，不代表它能處理新情境。

前三件是同一則通知的三種測試變體，這份演練先分開列；若用在真實工作，同一事件出現互相矛盾的證據，要先核對來源，不能各自結案。這次留下的是工作清單，還沒有實際去要證據、真人裁決或驗證工時下降。

回到一開始

• 查法留下了，分工也要寫清楚。 缺件由誰補、條件齊了由誰決定，不能留給 Claude 猜。
• Hook 檢查的是已寫下的條件。 這次攔下缺證據卻交給負責人的工作；看板又讓我發現，反方向的錯還沒被涵蓋。
• 團隊要接著做，需要看見進度、缺件與下一步。 只收到一句「完成」，仍不知道自己該接什麼。

今天看得到，是因為查核已留下紀錄。服務持續運行時，又該留下哪些訊號，讓我們及早發現問題？ 第四幕就從這裡開始。

參考資料：

• 官方依據： Claude Code 文件：Extend Claude with skills，〈Claude stops following a skill〉一節：每次都必須成立的規則移到 hook；同頁說明流程寫成 Skill、事實與約定留在 CLAUDE.md。
• 前篇： Day 19 檢查程式、Day 20 交接、Day 21 Eval（教學包）。
• 本文實作： 教學包 days/day22/lab-view：run-triage.py（提示與權限；--policy 加一行規則、--hook 掛上 Stop hook）、hook/check_worklist.py（hook 的檢查規則）、mod/（看板，需 Claude Code v2.1.287 以上）、demo/（看板示範資料）、三組各 3 次的工作清單、hook 紀錄與軌跡、build_view.py、FINDINGS.md。
• 打開看板： 在教學包目錄執行 claude --plugin-dir mod，再輸入 /work-view（需 Claude Code v2.1.287 以上）。目前目錄沒有執行結果時，看板讀的是內附的 demo/，看到畫面不代表已經重跑實驗。
• hook 檢查的已知缺口：「資料齊全，無需等待」仍會命中「資料」，「等待對方回覆」卻可能漏掉；清單不存在或讀取失敗時，目前也會放行。這些是程式檢視找出的缺口，尚未新增反例實跑。要把它當成正式關卡，還得定義明確的缺件狀態與讀取失敗處理，再補測。
• 資料範圍：
  • 31 筆皆為教學資料，三件業務是同一通知的三種變體；每組只跑 3 次，不估穩定度比例。
  • 更正：寫一行規則與 hook 兩組原本誤用了 37 筆輸入（Day 20 後來加的情境也被讀進去），已固定為原始 31 筆重跑，本文皆為重跑結果。
  • Day 21 另外補跑的 36 次難考卷是方法實驗，不進今天的 31 筆；人工的準備、查核、返工時間未記錄，寫未知、不補零。
  • 「還缺證據交給查核者」是本例的團隊約定，不是客觀正解。